Microsoft Corporation's prior art WINDOWS™ operating systems include built-in support for transparent file level encryption and decryption for volumes that are formatted with Microsoft Corporation's New Technology File System (NTFS). This feature, which is referred to as an encrypting file system (EFS), provides transparent encryption and decryption of files. A given folder can be marked as encrypted, and files created in the folder can be encrypted without any user intervention. WINDOWS™ EFS uses a symmetric file encryption key (FEK) for each file to encrypt and decrypt the file data. The FEK is encrypted with each user encryption public key and stored in the file EFS metadata information.
However, the WINDOWS™ EFS suffers from several limitations. Specifically, the sharing of encrypted files is limited to a small number of users, and users are required to have access to the encryption public keys of other users to grant those other users access to encrypted files. Some applications, such as WINDOWS™ WebDav Redirector, store and share encrypted files by creating an encrypted file in a local NTFS volume and extracting the file raw encrypted data using EFS backup application programming interface (API) functions. The raw encrypted data are then sent to a second computer where the data can be imported into a local NTFS volume using EFS restore API functions to recreate the encrypted file. Users on the second computer can access the encrypted file if they have a valid encryption certificate private key that decrypts the file encryption key.
Under this encryption system, users are required to explicitly and manually gather all certificates belonging to other users and add them to the shared encrypted files in order to grant any user access to an encrypted file, which may not be possible if some of the users' EFS certificates are not available at the time the shared files are created. This problem is further exacerbated by the fact that users can simultaneously have multiple valid EFS certificates, since EFS allows only a single certificate to be added to an encrypted file for a given user.
The prior art EFS has built-in support to provision each encrypted file with a recovery agent certificate that can be used for data recovery. However, there is no mechanism to select a set of recovery agent certificates at the folder level for use with all of the files in the folder, and users have no control over the recovery agent certificate set.
There are several challenges that need to be addressed to resolve these problems with the EFS. The problems that should be resolved include: (1) determining how to support the sharing of encrypted files among large groups of users without having to manually add each user certificate to each file; and, (2) enabling users to share encrypted files with other users without requiring access to their encryption certificates.
Collapsing multiple user certificates into a single group certificate that is shared among group users would eliminate the need to add other users' certificates to each file and would enable the system to scale to a very large number of users, to enable multiple users to share encrypted files. The system should ensure changes to group membership information are reflected in the group certificate and that only users in the group are allowed access to the encrypted files. This problem can be quite challenging, because the group certificate must be changed with every change in the group membership, since previous members of a group will continue to possess the group private key that enables them to gain access to files, even after leaving the group. Multiple group certificates should be maintained in order to enable access to encrypted files created before a group membership change occurred. Thus, management of group certificates must be made transparent and simple for this scheme to be viable, which is not a trivial problem.